31章 レイアウトとスタイル

akht.icon

体裁の整ったコードを視覚的かつ知的に楽しむことは、プログラマでなければ理解できない喜びだろう。自分の仕事に誇りを持つプログラマたちは、自分のコードの視覚的な構造を磨き上げることによって、芸術家としての大いなる満足感を得る。

プロジェクト全体を通じてこうした詳細に配慮することは、最初にコードの品質の差となり、最終的に保守性の差となる。

31.1 レイアウトの基本

改行や空白

31.1.2 フォーマットの基本定理

視覚的に優れたレイアウトはプログラムの論理構造を明らかにする

コードの構造をわかりやすくすること > コードの見た目を良くすること

31.1.3 人間によるプログラムの解釈とコンピュータによる解釈

愚か者はコンピュータが理解できるコードを書く。優秀なプログラマは人が理解できるコードを書く。──MartinFowler

インデントや空白の例

31.1.4 良いレイアウトの価値

コンピュータが読めるように書くことはほんのわずかなプログラミング作業で行えるが、他の人が読めるように書くことはプログラミング作業の大部分を占める。

チェスの例え話

プログラマも同じく、構造によって理解・記憶している

結論を言えば、プログラムを構造化する方法がどのようなものかということよりも、プログラムが一貫した構造になっているという事実の方がはるかに重要である。

31.1.5 信仰としてのレイアウト

レイアウトやフォーマットは宗教論争的になりがち

優秀なプログラマは、自分のレイアウトプラクティスに対して柔軟な考えを持っているはずであり、自分が使っているものより良いことが証明されたプラクティスがあれば、新しいプラクティスに慣れるまでに最初は不快感があるとしても、それを受け入れるべき

31.1.6 良いレイアウトの目標

結果が示しているのは、プログラミング能力のもろさである。上級プログラマは、プログラムがどう見えるべきかについて強い期待を持っている。そうした期待が表面的には悪気なく裏切られると、彼らの能力は一気に低下する。──ElliotSoloway、KateEhrlich

レイアウトは主観的な美しさの問題になりがちなので、何を優先するのかをはっきり決めておくといい

いいレイアウト方法の条件

コードの論理構造を正確に表現する

コードの論理構造の表現に一貫性がある

可読性を向上させる

変更に耐える

31.1.7 レイアウト目標を適用する方法

（省略）

31.2 レイアウトテクニック

31.2.1 空白

グループ化

空行

インデント

かっこ

31.3 レイアウトスタイル

ほとんどのレイアウト問題は、ブロック、つまり制御文に続くひとかたまりのステートメントに関係がある

31.4 制御構造のレイアウト

31.5 ステートメントのレイアウト

code:pseudo

customerPurchases = constomerPurchases + CustomerSales(CustomerID);

customerBill = customerBill + customerPurchases;

↑こういう代入での整列は悪い例として紹介されている

コードに変更があった場合に整列した状態に保つのが面倒という理由

31.7 ルーチンのレイアウト

31.8 クラスのレイアウト

クラスのメンバは次の順番で並べるといい

ヘッダーコメント

コンストラクタとデストラクタ

publicルーチン

protectedルーチン

privateルーチンとメンバデータ